Planning Your Move from SharePoint 2007 to 2010 : Planning Your Upgrade

With the release of Microsoft SharePoint Server 2010 and SharePoint Foundation, Microsoft has provided tools to execute an in-place upgrade of current SharePoint 2007 environments. These tools are designed to take existing SharePoint environments and upgrade the database schema, the presentation tier, and the middle tier application layer to either SharePoint Foundation 2010 or SharePoint Server 2010. In the end, current SharePoint applications will be fully functional, all existing capabilities will be enabled, and all existing custom and third-party Web Parts will continue to execute. Sounds simple, right? Well, it’s not.

The reality is that upgrading to the new version, if done right, will be very hard. This statement is not meant to scare or deter, but rather inspire and motivate. Really. The most critical task in this upgrade is planning. One possible scenario is to upgrade the software and leave the content and associated taxonomy alone; another choice might be that you choose not to upgrade but rather build from scratch. Technology can update the available functionality and introduce new database tables, but it cannot fix poorly designed taxonomies or appease overwhelmed system users. SharePoint 2010 planning involves investigation of new technology features, validation of the usefulness of those features in your environment, and integration of those features into your existing SharePoint framework. It will take time to do these steps properly, but it will pay off in the long run.

Upgrades are also a good time for some level of introspection and analysis. How has your current environment evolved since initial deployment, and where are things going strategically? There are lots of things to think about. Take a look at your organization’s use of SharePoint and consider the following questions. For those questions that you answer with a yes, think about how functionality, processes, and support will change in SharePoint 2010. For those questions answered with a no, will you introduce this functionality with SharePoint 2010 or continue to avoid it? Your answers will influence the means of your upgrade. And as we show you later, your answers also impact the timing of your upgrade.

• Do you have business processes that are driven by (or enabled within) SharePoint?

• Are you currently taking advantage of SharePoint-based or custom workflow?

• Do you have a culture of e-mailing documents as a means of workflow, review, and collaboration?

• Do users require offline access?

• Are your content contributors responsible for tagging your documents? Are they diligent in this effort?

• Are your portal, search, and collaboration taxonomies in good shape? Do your users agree?

• Do you have a well-defined list that is driving your decision to upgrade to SharePoint 2010?

• Are users ready for the move to Office 2010 and the new features of SharePoint 2010? Will you need to train them?

• Did you heavily customize your SharePoint 2007 environment? Are you invested in third-party or custom solutions?

• Does your current infrastructure comply with the SharePoint 2010 technical requirements (this includes 64-bit technology, increased RAM requirements, operating systems, and so on)?

• After your upgrade, will you present the new interface with the SharePoint 2010 ribbon, or will you wait to alter your user interface in a subsequent phase?

• Are you using Internet Explorer 7 or later?

As this list shows, there is a lot to think about when moving a well-established environment to the next version of the associated technology. Many of these are connected directly with business users and processes. Let’s look at some of these in more detail in the next sections.

Governance

As mentioned, one of the biggest challenges with this (or any) upgrade is executing on a well thought-out plan. You’ll need a plan not just for the technical component of applying new software, but more importantly, the details on what you will (or won’t) do with the software product after it is enabled. That’s where governance comes in. If you have a governance strategy in place for a current MOSS 2007 environment, modifying or adapting it to SharePoint 2010 is evolutionary. If you don’t have a governance policy today, consider developing one prior to the upgrade. This will establish clear rules on the use of native or customized SharePoint functionality. With this control in place, you can feel more comfortable in having some of the social computing components in SharePoint 2010 more widely used in a consistent manner. A governance plan is not a requirement for the upgrade but is critical to the ultimate success associated with post-upgrade usage.

SharePoint–Driven Business Processes

SharePoint Foundation 2010 and SharePoint Server 2010 are great tools that you can use to build more efficient business processes. With WSS 3.0 and MOSS 2007, many of these business processes (organizational workflow, e-mail-driven discussion threads, and lightweight project management, for example) were available but used sparingly.

SharePoint 2010 not only builds on previous business process capabilities, it integrates business processes deeper into the SharePoint environment by supporting additional features through the use of enhanced forms, workflow, Excel, Visio, and Access-based business applications and by incorporating line-of-business data into your portal with greater simplicity, resulting in an enhanced user experience. In addition, by introducing stronger social computing capabilities (tagging, for instance), SharePoint users can be consumers, producers, and influencers of content.

When planning for SharePoint 2010, it is important to identify and resolve barriers to business process adoption. Consider the following questions and associated recommendations:

• Is your organization ready to embrace potential changes to your business processes? User adoption and education are critical to introducing and leveraging change. Make sure everyone understands when the upgrade is happening and why.

• Does your current portal content organization support an upgrade to this new technology, or does it limit it? If users currently complain about the “findability” of content or the overall organization of intranet sites, an upgrade is a good time to make the necessary changes to increase ease of use.

• Are there technology limitations that would prevent adoption? Are you still using Office 2003? If yes, you should consider moving to Office 2010 (or at least Office 2007) before upgrading to SharePoint 2010.

• Is there sufficient end-user training available? Especially in an organization new to the ribbon user interface, end-user training (for content owners and administrators) is critical in advance of an interface change.

• Are the end user and administrator comfortable with the change? Communicate the changes and associated features of SharePoint 2010 well in advance of an upgrade so end users can process and embrace these changes.

• Is there adequate IT support? Ensure IT staff is properly trained and prepared for supporting the new features in SharePoint 2010; this includes direct (SharePoint administrators) and indirect (infrastructure personnel) resources.

Electronic Forms and Document Workflow

Does your organization still use paper-based forms? If so, are you looking to move to an electronic forms-based tool like InfoPath? Or can you take advantage of new flexibility with designing and customizing SharePoint list forms? Have you invested in data collection capabilities in SharePoint 2007, and how can these be enhanced?

How is workflow managed in your current SharePoint environment? Are rules in place to control the movement of data before it gets to SharePoint? One of the challenges of enabling the workflow capabilities in SharePoint 2007 (and this is still true with SharePoint 2010) was to have the discipline to enforce the rules around how the stages of the workflow are executed. Because the workflow is system-based, it needs to be well-defined. Typically, organizations use e-mail as the primary vehicle for workflow-based approval and validation. A number of e-mails are exchanged, decisions are made, and the workflow plan is ultimately executed, but the record of the decision is not typically stored with the document.

Planning for enabling electronic forms and/or automated workflow involves investigating the current forms and workflow processes within your organization and then defining how SharePoint will manage them. Define your users and document the decision points and time constraints of the various stages. This will help validate the usefulness of SharePoint’s forms and workflow tools and help define if and where it should be implemented.

Another thing to consider is that SharePoint 2010 takes electronic forms capabilities to the next level by enhancing the native workflow capabilities by integrating Visio services to allow a visual element to workflow design. Also, you can now use SharePoint Designer to edit and customize native SharePoint list forms. Why does this matter? If you’ve invested in workflow with SharePoint 2007, whether through custom application development and/or third-party product, you should investigate how these processes might be simplified or enhanced by using new native functionality.

It is also important to note that new features like Web-based forms and document workflow should be part of a broader functional upgrade and should only be used to meet specific business requirements. There is a danger in using new features of SharePoint 2010 for the sole purpose of building a stronger perception associated with Return on Investment (ROI) without clear ties to the business needs. If that happens, users are more discouraged than excited.

Your upgrade can be impacted based on your ability and willingness to alter existing data collection and workflow processes in SharePoint 2007. This may include simple edits to data entry forms or more advanced initiatives like migrating away from a third-party workflow or business process tool.

Preparing for Social Computing

Even with the introduction of various new technologies, the most likely place that organizational information exists, aside from inside people’s heads, is in their e-mail mailboxes. And we’re not talking about letters to grandma—we’re talking about important corporate knowledge like domain expertise, business intelligence, and key decisions that have been made. Most of this is information that can’t be accessed by other users and may walk out the door when an employee leaves, leaving the company without some important organizational knowledge.

How much corporate knowledge is lost in your organizational e-mail mailboxes? Does your company have a formal process in place to capture, catalog, and store information gathered through e-mail communications with peers, clients, and partners? One of the challenges in solving this problem with SharePoint 2007 was that while it was very good at storing structured content (such as documents), it was not heavily used for unstructured content (like discussions and tips and tricks). Nor did SharePoint 2007 encourage social contribution through ratings, comments, or tagging.

That said, SharePoint 2007 did offer a number of new alternatives to help in the storage and retrieval of unstructured knowledge. As an example, discussion threads were e-mail-enabled. That meant users no longer had to cut and paste to post questions or answers within a community of expertise. SharePoint 2007 site templates like blogs and wikis allow users and teams to publish information not captured in formal documents. The challenge, however, was that these types of social tools were used sparsely, mainly because organizations were concerned with giving “too much freedom” to users. This has changed as the world itself has changed. Now, with Internet applications like LinkedIn, Facebook, and Twitter, organizations see the value in capturing real-time, unstructured information.

Is your organization ready to embrace changes in the way people communicate using things like wikis and blogs? Are you willing to give employees the freedom to publish content in small, unformatted bits (think of Twitter)? Does your current SharePoint taxonomy support the inclusion of this new type of information? The promise of capturing “lost” corporate knowledge, buried in various employee e-mails, is very exciting. It does, however, come with some cost and cultural change. This is an important point. Often times (and especially true with SharePoint 2010), functional upgrades require one part technology and two part business process. Users must clearly understand the benefits of altered approaches to their activities. This is a requirement for general user adoption.

Will you look to take advantage of social computing capabilities in SharePoint 2010? If yes, do you have a formal plan for managing and monitoring these features? More importantly, does the content organization and/or security model you are using in SharePoint 2007 prevent or limit any part of your vision?

There are a couple of challenges here for existing SharePoint 2007 organizations. First, if you have “dabbled” in social computing capabilities (with native functionality or third-party add-ons), then you need to consider whether these will be left alone or redone with native SharePoint 2010. The impact on your upgrade is that these steps will happen after the physical upgrade and may or may not be addressed before the new launch. Second, if you have not formalized a social computing strategy but would like to with SharePoint 2010, then you will want to begin the education and design pieces before the upgrade so users are well-prepared when this functionality is made available to them.

Working with SharePoint Content Offline

How often are your SharePoint users, publishers, or readers disconnected from your corporate environment? Are your remote users forced to check out or download a collection of documents before getting on a plane? Are you concerned that document versions fall out of sync because of your remote users? SharePoint 2010, with the integration of SharePoint Workspace 2010, offers a vastly improved story around offline access to document library content. Users can easily retrieve, alter, and synchronize much of the data in SharePoint easily and automatically.

While this may sound like a wonderful thing, there are configuration issues. There are also levels of functionality that go from simple (copy files for offline access) to advanced (using SharePoint Workspace and letting users collaborate with peers or external parties). Are you currently using an offline solution? Would you like to introduce this capability with your upgrade? How many users will be impacted, and how will your organization be rewarded with the use of offline capabilities?

One goal of offline-enabled tools is to provide users with a strong sense that they are part of the larger organizational community. One way to achieve this is to provide things like Web-based meetings, Web cams, and instant messaging. In SharePoint terms, enabling users to always access the current version of a given document helps maintain synchronization across the user community because people will always be on the same page. 

Getting Your Timing Right: When Should You Upgrade?

SharePoint 2007 offered a great way to easily store information. That information, mostly in document form, was probably a mixture of content that was highly vetted and placed in SharePoint for storage and content that was iteratively managed through various major and minor versions.

With this, SharePoint 2007 introduced two important themes:

Have you taken advantage of these features in your current deployment? If you have and are looking to get to the next level, then an upgrade in the short term makes sense. If you have not but would like to, then include them in your post-upgrade strategy—but spend some time planning this before you push through an upgrade process. If you have not and are not likely to for some time, then you might want to consider deferring your upgrade until you have greater momentum within the current deployment.

Let’s take a look at how the answers might impact your readiness for an upgrade to SharePoint 2010. Table 1 highlights the questions and recommended action and timing.

Fixing Your SharePoint Structure

Does your current SharePoint navigation taxonomy (the structure and hierarchy of your site) make sense to users? What content do employees use on the portal? What content is missing or misplaced? Has your business changed, or will it change so that the current portal structure does not map to that vision? These are tough questions but ones that will ultimately have a significant influence on your upgrade path. SharePoint 2010 has some incredible new features, but they alone cannot make your portal “better.” It’s also hard to think about some of the items above (and how you might place and organize them) without having an appreciation for the stability of the current environment. Is an upgrade to SharePoint 2010 the right time to reorganize your portal content and better align it with what users want or the business demands? Or is your page and content organization stable and successful with less of a need for radical change? Can new functionality be included in these specific sections or added as additional pages without a major disruption to page organization? Your best tool in this piece of the planning will be a whiteboard. Draw your current portal structure. Think about where new functionality might be introduced. Change your marker color and start to make changes. In the end, which color dominates? This will help decide if an upgrade or migration is best.

Addressing New Features in SharePoint 2010

As you plan your SharePoint 2010 rollout, what are the two or three features in SharePoint 2010 that are organizational “killer applications” (that is, they draw your users to higher levels of adoption)? Will social computing functionality like content tagging draw people to participate more? Will more flexible content management give users a greater sense of empowerment? Will enhanced search help users find the “right” content faster? How do these new features fit into your existing portal taxonomy? The challenge is to sift through the long list of features of SharePoint 2010 and identify those that will be used and are useful to your organization. This list will help in your planning and will also excite users about the new system. Think about how these capabilities change what information is being stored in SharePoint and, more importantly, how users (readers, contributors, administrators) will be affected. With that list, decide how implementation may be impacted by changes to the existing site taxonomy, security model, or governance plan.

User Comfort, Skill Level, and Training

This is the big question: How ready are your users for SharePoint (and Office) 2010? What will the impact be on productivity and portal adoption if you chose to change the portal radically? How will you prepare employees for SharePoint 2010 and major changes for how business processes and content creation are managed? How can you do all of this within a timeline that works for the business units and IT? This is the piece most SharePoint implementers will forget. Even if Microsoft did have a “magic button” to seamlessly upgrade your current SharePoint environment to 2010 ... and all the features you really need are enabled ... and everything just worked ... would users be thrilled or terrified? The biggest disadvantage of having an existing SharePoint environment is that an upgrade means change—and change is scary. You’ll need to manage that fear by not overwhelming users, providing them with proper instructions, and giving them a clear roadmap around how to use the new features (and associated benefits). A SharePoint upgrade cannot happen in a vacuum. Users need to be informed and prepared. Manage risk by managing change. Only deviate from your existing framework if there are recognizable benefits to the user community in getting there.

Another important change with SharePoint 2010 is the introduction of the ribbon interface (first seen in Office 2007) for content administration. For those familiar with Office 2007, this interface change will require some basic training but will be somewhat transitional given the exposure to the ribbon in Office. For those who have not seen the ribbon, primarily because their organization is currently using Office 2003, the change in interface may be dramatic. You will need to decide whether to train users, possibly as part of an Office 2007 or 2010 launch, or defer the presentation by setting SharePoint 2010 to maintain the same user interface shown in SharePoint 2007. Obviously, the decision will impact the timing and process associated with your upgrade.

SharePoint 2007 Customizations

Finally, how much have you altered your existing SharePoint environment? Have you created site definitions? Have you unghosted pages (that is, have you detached from the standard template so that the page is now stored in the database)? Have you stayed with native functionality or created a highly customized environment? These items could have a major impact on the usefulness (and success) of Microsoft’s upgrade tools. If you have created a SharePoint environment with little to no customization, an automated upgrade may be more likely to succeed (but even the simplest In-place Upgrades have trouble sometimes). If you have customized SharePoint, you will need to identify those customization points and validate that each will successfully upgrade. Are you using third-party Web Parts? Have you created your own custom Web Parts? Will they work? Have you altered the underlying JavaScript or XML or ASPX pages? Take an inventory of changes you have made to SharePoint since you installed the software and use this list as a gauge for how hard an automated upgrade will be. Also, as a first step, run the native upgrade assessment tool that comes with SharePoint 2007 SP2 (STSADM.EXE -o preupgradecheck) to assess the likely success of your upgrade.

In addition, don’t forget to assess whether any custom tools or add-ons you are using are 1) still needed with SharePoint 2010 (that is, do native components now provide the custom functionality?) and 2) operational in a SharePoint 2010 environment (that is, does the vendor support the new platform, or does the custom code still work?). You will need to determine this for all non-native components that you currently manage.